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Abstract 

The  weblog  from  theaviationist.com  on  Aug  13,  2014  noted  that  an  Air  Force 
aircraft  taking  part  in  strikes  against  Taliban  leaders  in  Afghanistan  was  monitored 
and  tracked  via  open  source  Internet  methods.  During  the  flight,  the  Automatic 
Dependent  Surveillance-Broadcast  (ADS-B)  transmitter  was  unintentionally  turned 
on.  In  sensitive  mission  operations,  such  as  air  operations  in  theater,  the  broadcasting 
of  ADS-B  messages  poses  a  serious  security  concern,  but  the  small  message  payload  of 
ADS-B  transmissions  renders  encryption  standards  such  as  AES  unsuitable.  Format¬ 
preserving  encryption,  a  technique  already  in  use  on  small  message  sizes  such  as  credit 
card  numbers,  provides  a  suitable  implementation  of  strong  symmetric  key  encryption 
for  the  military  context. 

This  research  proposes  a  Secure  ADS-B  (SADS-B)  system  which  utilizes  a  bump- 
in-the-wire  approach  for  encryption  and  decryption  of  ADS-B  messages.  SADS-B 
is  a  proof-of-concept,  real-time  encryption/decryption  system  utilizing  the  format¬ 
preserving  encryption  algorithm  FFX.  This  research  details  the  design  of  the  SADS- 
B  system  and  characterizes  the  prototype’s  performance  using  the  following  metrics: 
detection  and  error  rates,  operational  latency,  and  utilization  of  resources  on  the 
underlying  held  programmable  gate  array  (FPGA)  hardware. 

Findings  include  sub-millisecond  operational  latency  for  each  encryption  and  de¬ 
cryption,  full  data  rate  throughput  capability  for  ADS-B,  and  approximately  50% 
utilization  of  the  available  FPGA  resources.  Overall,  Endings  suggest  that  a  layered 
security  system  such  as  SADS-B  is  suitable  for  increasing  the  security  of  ADS-B  use 
in  the  military  context. 
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DESIGN  AND  CHARACTERIZATION  OF  A  SECURE  AUTOMATIC 
DEPENDENT  SURVEILLANCE-BROADCAST  PROTOTYPE 

I.  Introduction 


1.1  Background  and  Motivation 


On  August  10,  2014,  a  USAF  E-llA  aircraft  circling  the  Ghazni  region  of  Afghanistan 
could  be  tracked  by  anyone  in  the  world  with  Internet  access  [3].  Figure  1  is  a  screen 
capture  of  what  an  Internet  browser  would  have  displayed.  According  to  the  web¬ 
site  The  Guardian,  there  was  a  coincident  NATO  attack  in  the  region  [12].  The 
E-llA  aircraft  was  transmitting  an  Automatic  Dependent  Surveillance-Broadcast 
(ADS-B)  signal  during  its  flight,  which  contains  its  precise  location  information, 
thus  allowing  any  nearby  ADS-B  receiver  to  be  used  to  track  the  location  of  the 
aircraft  during  a  combat  mission. 
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Figure  1.  Open  source  flight  track  of  military  aircraft  [3]. 
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In  sensitive  mission  operations,  such  as  air  operations  in  theater,  the  broad¬ 
casting  of  ADS-B  messages  poses  a  serious  security  concern  [17,  18,  20].  Previous 
research  has  evaluated  the  possibility  of  encrypting  the  data  contained  in  ADS-B 
messages  [1,  11],  identifying  the  expected  utility  of  some  various  symmetric  key  en¬ 
cryption  algorithms. 

ADS-B  is  one  of  the  major  component  systems  of  Next  Generation  Air  Trans¬ 
portation  System  (NextGen),  a  phased  upgrade  program  being  rolled  out  by  the 
Federal  Aviation  Administration  (FAA)  to  improve  the  robustness  of  United  States 
National  Airspace  System  (NAS).  The  benefits  of  NextGen  are  notable,  as  it  has 
the  potential  to  improve  the  efficiency  and  safety  of  commercial  flight  in  the  United 
States.  ADS-B  specihcally  increases  the  precision  of  positioning  information  avail¬ 
able  to  everyone  equipped,  by  collecting  Global  Positioning  System  (GPS)  position 
information  and  broadcasting  it  to  the  surrounding  area. 

The  United  States  Air  Force  (USAF)  has  identified  benefits  from  implement¬ 
ing  and  using  ADS-B,  centered  on  enhanced  safety  and  mission  effectiveness  [13]. 
While  commercial  aircraft  may  fly  in  close  proximity  out  of  necessity  due  to  re¬ 
stricted  and/or  crowded  airspace  around  an  airport,  military  aircraft  often  inten¬ 
tionally  operate  at  close  proximity,  sometimes  for  long  periods  of  time  in  such  mis¬ 
sion  areas  as  formation  flying  and  air  refueling  [13].  Radar  is  the  primary  sensor 
used  for  automatically  retrieving  position  information  about  other  aircraft,  and 
its  precision  is  weak.  The  result  is  the  need  for  verbal  adjustments  between  pilots 
based  on  visual  contact.  ADS-B,  if  implemented  and  integrated  into  planning  and 
tracking  and  navigation,  has  the  potential  to  increase  mission  safety,  effectiveness, 
and  efficiency  in  areas  like  air  refueling. 

However,  NextGen  in  such  a  military  context  presents  security  challenges  across 
the  fundamental  aspects  of  security:  conhdentiality,  integrity,  availability,  authenti- 
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cation,  and  non-repudiation.  The  FAA  has  directly  acknowledged  security  weak¬ 
nesses  in  conhdentiality  and  authentication  [8].  Some  prior  work  has  started  to  ad¬ 
dress  weaknesses  in  the  underlying  ADS-B  system,  including  in  a  military  context. 
Recently,  research  has  illuminated  format-preserving  encryption  (FPE)  as  a  mecha¬ 
nism  to  provide  conhdentiality  and  also  integrity  to  an  extent  [10].  Follow-up  work 
was  also  conducted  to  evaluate  a  potential  hardware  design  in  simulation  [1]. 

1.2  Problem  Statement 

This  research  presents  the  design,  development,  and  testing  of  a  proof-of-concept 
Secure  ADS-B  (SADS-B)  prototype,  operable  in  two  modes:  either  (1)  as  part  of 
the  transmit  chain,  capable  of  receiving  an  ADS-B  message,  encrypting  it,  and 
transmitting  a  SADS-B  message  in  its  place,  or  (2)  as  part  of  the  receive  chain,  ca¬ 
pable  of  receiving  a  SADS-B  message,  decrypting  it,  and  transmitting  the  original 
ADS-B  message. 

1.3  Research  Objectives 

The  goal  of  this  research  is  to  design,  develop  and  characterize  a  complete 
SADS-B  prototype,  through  the  following  steps: 

•  Design  and  develop  SADS-B  prototype  system 

•  Verify  correctness  of  prototype  implementation  (system  and  component-level) 

•  Evaluate  the  performance  of  prototype 

—  latency  (system  and  component-level) 

—  preamble  synchronization  component 

—  bit-level  pulse-position  modulation  (PPM)  demodulator 
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•  Evaluate  required  field-programmable  gate  array  (FPGA)  resources  for  full 
data  rate  implementation  of  Format-preserving  Feistel-based  Encryption  (FFX) 

1.4  Approach 

The  research  objectives  are  approached  systematically  using  an  incremental  ap¬ 
proach  through  a  series  of  analysis,  modeling  and  simulation,  hardware  simulation, 
and  hardware  verihcation.  The  system  builds  on  previous  research  conducted  by 
Finke  [11],  which  validated  a  suitable  FFX  implementation.  To  complete  the  full 
bump-in-the-wire  (BITW)  concept,  additional  digital  components  are  necessary. 

For  these  components,  the  MATLAB®  2014b  programming  environment  was  used 
to  develop,  analyze  and  model  hnite  impulse  response  (FIR)  designs  for  synchro¬ 
nization,  demodulation.  Cyclic  Redundancy  Check  (CRC)  validation,  packet  gener¬ 
ation,  and  modulation.  The  hardware  design  for  each  component  is  then  developed, 
including  fully  unrolled  encryption  and  decryption  engines.  Using  Active-HDL® 

9.3  and  ModelSim®  10.4,  each  component  design  is  then  simulated  and  verihed, 
followed  by  the  end-to-end  design.  Finally,  Xilinx  ISE  14.7  Design  Suite  is  used  to 
implement  the  verihed  design  in  hardware  on  a  Kintex-7K410T  FPCA,  onboard  a 
Universal  Software  Radio  Peripheral  (USRP™)  X310  which  normally  operates  as  a 
Soft  ware- Dehned  Radio  (SDR).  The  top  level  FPCA  design  of  the  X310  is  modihed 
to  support  standalone  operation,  more  representative  of  the  BITW  use  case.  Addi¬ 
tionally,  the  FPCA  resources  (Look-Up  Tables  (LUTs),  registers  and  memory)  con¬ 
sumed  by  the  SADS-B  modules  are  evaluation  using  results  reported  in  ISE  Design 
Suite. 

To  assess  performance,  external  analysis  of  the  hardware  systems  using  an 
Keysight  N5182B  MXC  Vector  Signal  Generator  and  a  Teledyne  LeCroy  760Zi-A 
oscilloscope  are  used  to  retrieve  a  true  operational  latency  of  the  system.  Finally,  a 
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second  USRP™  is  used  alongside  the  N5182B  to  assess  the  operational  throughput. 
The  results  are  assessed  in  the  context  of  ADS-B  specihcations  [21]  and  in  compari¬ 
son  to  the  hndings  of  previous  research  utilizing  an  iterative  looping  design  [1]. 

1.5  Organization 

Chapter  II  provides  an  in-depth  literature  review  on  the  use  of  ADS-B  within 
NextGen,  discusses  previous  research  which  addressed  security  issues  with  NextGen, 
and  the  hardware  platform  on  which  the  SADS-B  prototype  will  be  developed. 
Chapter  III  details  the  SADS-B  prototype  system,  as  well  as  underlying  algorithms 
developed  during  the  course  of  this  research.  Chapter  IV  hrst  describes  the  method¬ 
ology  for  verihcation  and  assessing  the  performance  of  the  SADS-B  prototype.  Then 
it  presents  the  results,  discussion,  and  analysis  for  verihcation  and  performance. 
Lastly,  Chapter  V  contains  a  summary  of  contributions  as  a  result  of  this  research, 
conclusions  drawn  from  it,  and  recommendations  for  future  SADS-B  research. 
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II.  Background 


This  chapter  presents  necessary  background  information  to  provide  a  context 
for  assessment  and  characterization  of  a  SADS-B  prototype.  It  summarizes  the 
emergence  of  ADS-B  at  part  of  systemic  upgrade  to  Air  Traffic  Control  (ATC)  in 
the  United  States,  followed  by  details  about  previous  work  in  augmenting  the  se¬ 
curity  of  ADS-B  including  encryption  techniques.  Last,  this  chapter  provides  an 
overview  of  the  hardware  platform  on  which  the  prototype  is  developed  and  imple¬ 
mented. 

2.1  National  Airspace  System 

The  primary  purposes  of  ATC  are  to  prevent  collisions  between  aircraft  and  to 
provide  a  safe,  orderly  and  expeditious  flow  of  air  traffic  [9].  For  flights  under  the 
18,000  ft  level,  called  Flight  Level  180  (FL180),  the  pilot  has  the  responsibility  to 
maintain  safe  flying  distance  from  other  aircraft.  This  lower  altitude  traffic  is  also 
referred  to  as  Visual  Flight  Rules  (VFR)  traffic.  For  flights  above  FL180,  called  In¬ 
strument  Flight  Rules  (IFR)  traffic,  the  federal  government  is  responsible  for  ATC 
and  has  been  since  the  Federal  Aviation  Act  of  1958.  The  FAA  is  the  organization 
delegated  the  responsibility  of  handling  ATC,  and  they  use  the  NAS  system  to  do 
so.  The  NAS  is  a  collection  of  facilities,  system,  equipment,  procedures,  and  air¬ 
ports  operated  by  thousands  of  ground-based  personnel  [7].  There  are  690  ATC 
facilities  with  associated  systems  and  equipment  to  provide  radar  and  communica¬ 
tion  service,  divided  into  21  regions,  each  with  their  own  Air  Route  Traffic  Control 
Center  (ARTCC).  The  Air  Traffic  Control  System  Command  Center  (ATCSCC)  is 
the  headquarters  over  all  the  ARTCCs.  There  are  two  main  influences  that  drive 
decisions:  traffic  congestion  and  weather.  When  actions  need  to  be  taken  to  mod- 
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ify  traffic  flow,  it  happens  through  airline  personnel,  traffic  management  specialists, 
and  air  traffic  controllers. 

For  the  NAS  to  be  effective,  it  needs  location  information  (position,  heading, 
altitude)  for  all  IFR  traffic,  at  all  times.  This  has  been  primarily  accomplished 
through  the  use  of  radar  (providing  range  and  azimuth  data)  and  Mode  C  (pro¬ 
viding  altitude  information).  However,  there  are  significant  limitations  to  this  ap¬ 
proach.  First,  voice  communication  with  a  pilot  are  the  means  of  control  for  an  air 
traffic  controller.  Second,  long-range  Air  Route  Surveillance  Radars  (ARSRs)  can 
only  typically  cover  a  200  NM  radius  and  are  expensive  to  maintain  [7].  There  are 
only  about  100  ARSRs  in  operation  in  the  United  States.  Additionally,  navigation 
aid  facilities  (NAVAIDs)  provide  beacons  that  increase  the  available  airspace,  pro¬ 
viding  a  means  to  connect  between  radar  sites.  Nonetheless,  fiights  at  IFR  altitudes 
are  restricted  to  routes  that  overfiy  NAVAIDs  or  ARSRs,  leading  to  many  funnel 
points  in  the  network.  This  is  especially  true  near  airports,  where  there  are  often 
only  one  or  two  NAVAIDs  for  departing  aircraft  to  egress  past. 

Radar  only  refreshes  approximately  once  every  12  seconds,  and  has  a  margin 
of  error  of  300m.  A  more  accurate  and  accessible  source  of  position  information  is 
GPS,  which  has  been  around  since  1973.  When  GPS  is  augmented  with  ionospheric 
correction  data  from  Wide  Area  Augmentation  System  (WAAS),  it  can  accurately 
estimate  position  within  2  meters  [7].  Additionally,  all  IFR  aircraft  are  already  re¬ 
quired  by  the  FAA  to  have  GPS  receivers  onboard. 

2.2  NextGen 

The  future  vision  of  the  Next  Generation  Air  Transportation  System  (NextGen) 
program  relaxes  many  of  the  restrictions  on  IFR  fiight  due  to  mechanisms  that  re¬ 
duce  reliance  on  radar.  Several  technologies  are  needed  to  achieve  this  end  vision. 
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NextGen  includes  technologies  such  as  performance  based  navigation,  low  visibil¬ 
ity  aids,  and  electronic  flight  bag  [23].  It  also  establishes  data  communications  that 
reduce  the  amount  of  required  verbal  communication  between  air  traffic  controllers 
and  pilots.  Finally,  NextGen  adds  a  system  that  automatically  delivers  high  preci¬ 
sion  GPS  data  to  both  pilots  and  air  traffic  controllers.  This  system  is  called  Au¬ 
tomatic  Dependent  Surveillance-Broadcast  (ADS-B),  and  it  has  the  potential  to 
eliminate,  or  at  least  drastically  reduce,  reliance  on  radar. 

2.3  ADS-B 

As  the  name  suggests,  ADS-B  automatically  transmits  position  information, 
dependent  on  GPS,  to  surveillance  stations  (i.e.  air  traffic  controllers)  via  data 
broadcast.  ADS-B  consists  of  two  major  subsystems:  ADS-B  Out  and  ADS-B  In. 
ADS-B  Out  is  the  broadcast  message  (by  an  aircraft,  vehicle,  or  ground  radio  sta¬ 
tion)  containing  an  aircraft  identifier  and  the  GPS-based  latitude,  longitude,  and 
altitude  positioning  information.  ADS-B  In  is  the  receiving  end,  implemented  by 
air  traffic  controllers  and  aircraft  alike,  enabling  reception  and  display  of  nearby 
vehicles  without  reliance  on  radar. 

Because  ADS-B  Out  was  designed  to  be  universal,  it  is  not  encrypted  in  any 
way.  The  message  format  for  an  ADS-B  Out  broadcast  is  shown  in  Figure  2.  The 
cleartext  transmission  of  this  data  presents  a  security  risk.  As  described  in  Sec¬ 
tion  1.1,  this  risk  is  especially  true  in  military  operations  that  are  sensitive,  such 
as  combat  operations. 
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Figure  2.  ADS-B  DF-17  message  format  [21]. 


2.4  Related  Work 


Prior  research  efforts  have  made  progress  towards  more  secure  implementations 
of  ADS-B,  specifically  utilizing  the  DF-17  message  which  is  the  primary  ADS-B 
Out  message  in  use  by  the  USAF. 

The  Communications  Security  (COMSEC)  vulnerabilities  associated  with  ADS- 
B  were  identified  by  Purton  et  al  [20],  and  later  expounded  upon  by  McCallie  [18], 
elaborating  on  the  Operational  Security  (OPSEC)  issues  with  a  military-specific  fo¬ 
cus.  Magazu  illustrated  the  simplicity  of  performing  an  injection  attack  using  SDR, 
an  inexpensive  Commercial- Off-The-Shelf  (COTS)  piece  of  equipment  [17]. 

The  path  to  encryption  began  with  Jochum  [15],  who  proposed  using  symmet¬ 
ric  key  cryptography  to  encrypt  the  message  payload  during  sensitive  operations 
and  tailored  the  recommendation  around  the  use  of  the  DF-19  header  code,  which 
is  already  reserved  for  military  use  in  the  ADS-B  specifications  [21].  Finke  affirmed 
the  plausibility  of  using  this  type  of  cryptography,  and  analyzed  the  theoretical  im¬ 
plementation  of  FPE  to  handle  the  unusual  bit  width  of  messages  [11].  Finally,  Ag- 
beyibor  confirmed  the  strength  of  three  different  FPE  algorithms,  simulating  an 
FPGA-based  design  and  assessing  expected  FPGA  resources  required. 

2.5  Format  Preserving  Encryption 

The  need  to  encrypt  cleartext  communications  containing  position  information 
in  a  military  context  is  not  new.  Automatic  Identification  System  (AIS)  is  a  com¬ 
mercial  system  used  to  receive  and  transmit  position  information  for  sea  vessels, 
similar  to  the  function  of  ADS-B  for  aircraft.  Like  ADS-B,  messages  are  transmit¬ 
ted  in  cleartext,  but  with  a  message  length  of  128-bits.  To  keep  its  transmissions 
confidential,  NATO  created  Warship- Automatic  Identification  System  (W-AIS), 
which  encapsulates  and  encrypts  one  or  more  AIS  messages  as  its  payload  (in  incre- 
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ments  of  128-bits,  up  to  a  maximum  of  896  bits),  prior  to  broadcast  [14],  Other  W- 
AIS  receivers  are  able  decrypt  the  messages  (using  a  symmetric  key)  and  relay  the 
identification  and  position  information  to  the  display  console.  W-AIS  may  directly 
use  Blowfish  or  Advanced  Encryption  Standard  (AES)  algorithms,  as  both  algo¬ 
rithms  have  been  approved  and  are  well  suited  for  the  128-bit  AIS  message  length. 

i  n-i 


Figure  3.  FFX  encryption  structure  [2]. 

However,  ADS-B  has  a  much  shorter  112-bit  fixed-length  message,  requiring 
the  use  of  format-preserving  encryption  (FPE).  In  general,  FPE  algorithms  are 
not  dependent  on  a  specihc  message  size  or  format  to  be  effective.  More  specih- 
cally,  they  will  generate  a  ciphertext  in  the  same  radix  and  number  of  digits  as  the 
plaintext  input,  regardless  of  the  key  size  utilized.  The  FPE  algorithm  evaluated 
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by  Finke  for  use  with  ADS-B  is  FFX  [11],  shown  in  its  generalized  form  graphically 
in  Figure  3.  Fk  (as  shown  in  the  Algorithm  1)  is  a  one-way  function  that  gives  the 
encryption  method  its  strength. 


Algorithm  1  Function  F  using  CBC-MAC  of  AES  [11] 

function  F(n,  T,  i,  B) 

vers  •<—  1;  t  •<—  |T|  in  bytes 

[versY  II  [methodY  ||  [additionY  ||  [radixY  ||  [nY  ||  [spUt(n)Y  ||  [rnds{n)Y  ||  [t]® 

Q^T\\  II  l-Jl  II  o64-|B|  II  ^ 

Y  ^CBC-MAC(P  II  Q) 
return  y[129  —  split {n)..\2'S\ 

end  function 


function  CBC-MAC(toi  ||  m2) 
a:  ^  AESif(mi  XOR  0) 

Y  ^  AESx(to2  XOR  X) 

return  Y 
end  function 


>  Note:  [s]®  denotes  the  Pbyte  string  that  encodes  the  number  s 


The  function  Fk  used  for  FFX  by  Finke  is  an  implementation  of  AES.  The 
128-bit  implementation  used  performs  a  truncation  step,  making  it  a  one-way  func¬ 
tion.  The  implementation  is  maximally  balanced,  with  52  bits  in  each  half  of  the 
Feistel  structure,  as  shown  in  Figure  4. 
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Figure  4.  FFX  bits  superimposed  on  ADS-B  DF-17  message  [11]. 
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2.6  USRP™  X310 


Ettus  Research’s  USRP™  X310  is  a  highly  customizable  FPGA-based  radio  re¬ 
ceiver  transmitter.  The  USRP^”  devices  typically  function  as  a  SDR,  as  depicted 
in  Figure  5.  That  is,  they  function  as  a  slave  to  a  master  personal  computer  (PC) 
running  GNU  Radio,  which  controls  the  sample  rate,  tuning,  digital  down  conver¬ 
sion  (DDC),  and  digital  up  conversion  (DUG)  in  real  time.  All  other  processing 
(such  as  a  generating  a  spectrogram  from  the  data)  is  accomplished  on  the  master 
PC.  For  example,  in  receive  mode,  after  the  DDC  chain,  in-phase  (I)  and  quadra¬ 
ture  (Q)  samples  are  transmitted  over  the  Ethernet  connection  (see  Figure  5). 


Figure  5.  USRP™  X310  receive  and  transmit  processing  chains  [6]. 


A  similar  model  (the  USRP™  N210)  was  previously  used  by  Magazu  [17]  in 
creating  a  fake  flight  track  of  ADS-B  messages. 

The  X  Series,  shown  in  Figure  6,  are  higher  sample  rate  devices  with  a  more 
capable  FPGA,  the  Xilinx  Kintex-7.  Additionally,  Ettus  Research  has  made  the 
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Figure  6.  USRP™  X310  [6], 


hardware  description  language  (HDL)  source  code  available  for  modification.  Writ¬ 
ten  in  Verilog,  the  availability  of  the  source  code  is  essential,  as  a  PC-peripheral 
device  would  suit  the  intended  purpose  as  an  avionics  prototype.  To  overcome  this 
limitation,  the  SADS-B  module  will  be  developed  in  Very  High  Speed  Integrated 
Circuit  Hardware  Description  Language  (VHDL)  and  implemented  alongside  the 
provided  source  code. 
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III.  System  Design  and  Implementation 


This  chapter  begins  with  a  high-level  concept  and  minimum  performance  re¬ 
quirements  for  the  SADS-B  prototype  system,  based  on  ADS-B  specifications  [21] 
It  then  delves  into  the  design  specihcs  and  implementation  details  of  the  system. 


3.1  BITW  Concept 

Along  the  lines  of  W-AIS,  SADS-B  will  modify  a  normal  ADS-B  message  (as  in 
Figure  2  on  page  8)  by  encrypting  the  bits  shown  in  Figure  4  on  page  11.  In  a  hnal 
implmentation,  this  would  most  likely  be  implemented  by  modifying  an  existing 
ADS-B  transponder,  but  for  proof  of  concept  purposes  and  to  provide  an  interim 
approach,  a  BITW  approach  is  suitable. 


Data  Out  Data  In 


-►i  BITW  Device 


Secure  Data  Out 


Secure  Data  In  . 


►,  BITW  Device 


Data  Out  Data  In 

- ► 


Figure  7.  BITW  concept  diagram. 

As  dehned  in  IETF  RFC4949,  bump-in-the-wire  (BITW)  is  “An  implementa¬ 
tion  approach  that  places  a  network  security  mechanism  outside  of  the  system  that 
is  to  be  protected”  [22].  Figure  7  illustrates  a  system  with  a  set  of  paired  BITW 
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devices  that  perform  a  security  function  between  two  legacy  devices.  The  legacy  de¬ 
vices  need  no  special  conhguration  or  context  in  order  to  communicate  through  the 
BITW  device.  A  widely  used  implementation  of  a  BITW  security  approach  is  Inter¬ 
net  Protocol  Security  (IPSec)  devices  between  Internet  Protocol  (IP)  routers  that 
need  to  traverse  an  untrustworthy  connection.  The  packets  are  transmitted  to  the 
IPSec  devices,  which  encapsulate  and  encrypt  the  received  packet  before  transmit¬ 
ting  it  across  the  Internet. 

In  the  context  of  ADS-B  transmission,  the  ADS-B  Out  is  intercepted  by  the 
BITW  encryptor,  translating  the  signal  to  a  secure  signal,  SADS-B  Out.  The  re¬ 
verse  occurs  on  the  receiving  end.  The  proof-of-concept  prototype  resulting  from 
this  research  serves  either  as  the  SADS-B  Encryptor,  SADS-B  Decryptor,  or  both. 


Figure  8.  BITW  approach  to  securing  ADS-B. 

Because  the  BITW  encryption  and  decryption  only  apply  to  specihc  messages 
(DF-17)  messages,  an  important  option  is  the  pass-through  of  the  received  signal. 
This  would  allow  the  pass-through  of  all  other  messages  (ADS-B  or  other)  on  the 
1090  MHz  frequency. 
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3.2  Latency  Requirement 


The  ADS-B  system  is  not  packet-based,  as  it  functions  through  broadcast  mes¬ 
sages.  The  messages  are  also  time-sensitive,  as  the  FAA  DO-260B  specihcation  [21] 
specihes  a  100  ms  window  for  ADS-B  position  messages.  Further,  the  receiver  itself 
is  specihed  as  having  ±  50  ms  tolerance,  which  leaves  only  50  ms  maximum  allow¬ 
able  operational  latency  for  the  SADS-B  BITW  device. 

The  in-line  BITW  architecture,  low  latency,  and  pass-through  capability  re¬ 
quirements  for  an  effective  SADS-B  prototype  support  the  use  of  an  FPGA-based 
hardware  environment. 

3.3  Sampling  Rate 

For  any  digitally  sampled  signal,  the  minimum  required  sampling  rate,  Fg^min, 
is  twice  the  analog  bit  rate,  according  to  the  sampling  theorem.  In  the  case  of  PPM, 
two  samples  are  simply  needed  to  determine  the  location  of  the  pulse:  in  the  hrst  or 
second  half  of  a  bit  frame.  In  ADS-B,  the  PPM  bit  rate  is  1  Mb/s,  so  the  required 
Fg^rnin  D  2  MS/s. 

Oversampling  is  an  effective  means  to  reduce  receiver  noise  in  digital  systems. 

Fg 

Oversampling  effectively  increases  the  resolution  bandwidth  causing  the 

noise  A^^o  to  reduce,  per  Equation  1,  where  N  is  the  noise  power. 

N  =  No(3  (1) 

It  can  also  be  construed  in  terms  of  noise  power  per  sample  Ngampie,  according  to 
Equation  2,  where  M  is  the  oversampling  factor. 

N sample  =  NqM  (2) 
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Section  1.4. 1.1  of  DO-260B  recommends  an  oversampling  factor  of  at  least 
4,  but  recommends  5  or  more  based  on  tests  conducted  by  RTCA,  Inc  [21].  The 
SADS-B  prototype  design  in  this  research  follows  this  recommendation  with  an 
oversampling  factor  of  5,  such  that  Fg  =  10  MS/s.  Each  pulse  width  used  for  sam¬ 
pling  is  5  samples.  During  both  preamble  detection  and  demodulation,  the  edge 
samples  (samples  adjacent  to  transition  zones)  are  ignored.  Figure  9  depicts  the 


Figure  9.  Possible  conditions  during  sampling  for  PPM. 

driving  factor  for  this,  being  the  potential  for  anomalies  (i.e.  increased  noise)  in 
samples  in  transition  zones.  As  a  mechanism  to  reduce  this  noise,  the  samples  near¬ 
est  the  transition  zones  are  ignored.  This  reduces  the  effective  oversampling  rate  to 
3,  again  following  the  recommendations  from  the  enhanced  detection  guidelines  in 
Section  1. 4. 1.1  of  DO-260B  [21]. 

3.4  Top-Level  Design 

Figure  10  shows  the  top  level  design  of  the  USRP^”  X310,  modihed  for  use  as 
the  SADS-B  prototype.  The  SADS-B  Module  as  depicted  in  Figure  10  is  the  top- 
level  VHDL  component,  which  is  the  overall  focus  of  this  chapter. 

The  built-in  analog  components  in  the  USRP^”  SBX-40  daughtercard  perform 
coarse  tuning  for  the  Mode  S  carrier  frequency  of  1090  MHz.  The  frequency  re¬ 
sponse  for  the  circuit  is  shown  in  Figure  49  in  Appendix  A.  This  is  performed  by 
setting  a  specihc  controller  on  the  board,  which  drives  a  numerically  controlled  os- 
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Figure  10.  SADS-B  top  level  design.  Modified  from  [6]. 


cillator  (NCO)  to  mix  the  1090  MHz  signal  down  to  baseband.  It  is  then  passed 
through  a  40  MHz  anti-aliasing  low-pass  hlter  (LPF)  before  conversion  to  digital 
in  the  analog  to  digital  converter  (ADC)  component,  from  which  the  I  and  Q  data 
are  transmit  to  the  FPGA  at  a  sampling  rate  of  200  MS/s.  This  level  of  sampling  is 
nnnecessary  for  the  1  Mb/s  PPM  signal  of  ADS-B,  so  the  next  step  is  to  downsam¬ 
ple  the  the  signal. 

Internal  to  the  FPGA,  Ettus  Research  has  already  designed  conhgurable  DDC, 
reqnired  for  normal  operation  of  the  USRP^*^  when  it  operates  in  SDR  mode,  as 
previously  shown  in  Fignre  5  on  page  12.  These  Verilog-based  HDL  components  are 
snitable  for  use  in  the  SADS-B  prototype  design.  In  the  Ettus  Research  DDC  de¬ 
sign,  downsample  occnrs  throngh  three  snccessive  ronnds  of  hltering  throngh  a  LPF 
followed  by  downsampling.  The  LPF  in  each  step  is  set  to  a  stop  band  freqnency 
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of  the  I  the  inverse  of  the  downsample  rate  for  that  step,  as  in  Equation  3,  where 
Fs  is  the  input  sampling  rate  for  that  downsample  step  and  M  is  the  downsample 
factor. 


B 


If 

2M 


(3) 


In  the  Ettus  DDC  design,  the  first  two  steps  are  either  turned  on  or  off  with 
a  hard  set  downsample  rate  of  2.  The  third  downsample  step  is  always  on,  with  a 
conhgurable  integer  downsample  rate.  For  example,  in  the  case  of  a  target  sam¬ 
ple  rate  of  =  lOMS/s,  as  discussed  in  the  next  section,  the  steps  would  be 
[ON, ON, 5],  equating  to  a  downsampling  factor  of  2  x  2  x  5  =  20. 

In  the  output  chain,  the  order  of  operations  is  essentially  reversed.  Three  sim¬ 
ilarly  configurable  interpolation  steps  bring  the  sample  rate  back  up  to  200  MS/s 
from  10  MS/s.  First  interpolation  step  is  conhgurable  by  integer  factor,  which  is 
again  set  to  5.  The  next  two  steps  are  a  factor  of  2,  and  both  are  set  to  “on.”  Af¬ 
ter  each  interpolation  step,  there  is  an  interpolation  hlter,  which  removes  high  fre¬ 
quency  noise.  The  stop  band  for  this  hlter  is  set  according  to  Equation  3,  where  Fg 
is  the  output  sampling  rate  after  upsampling. 

The  FPGA-based  SADS-B  subsystem,  which  is  the  focus  of  this  thesis,  consists 
of  two  modules:  the  SADS-B  Encryption  Module  and  SADS-B  Decryption  Module. 
While  similar,  there  are  diherences  primarily  in  packetization  and  CRC  validation. 
The  block  diagrams  are  shown  in  Figures  11  and  12,  respectively. 

The  clock  rate  for  all  the  components  in  the  design  is  the  native  FPGA  200 
MHz  clock.  Every  block  shown  in  the  functional  block  diagrams  in  Figures  11  and 
12  have  clock  inputs  (200  MHz)  and  clock  enable  inputs  (10  MHz)  that  drive  the 
operation  of  the  components  (not  shown  in  the  diagram). 
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Figure  11.  Functional  block  diagram  for  the  SADS-B  encryption  module. 
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Figure  12.  Functional  block  diagram  for  the  SADS-B  decryption  module. 
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3.5  Preamble  Detection  and  Synchronization 


The  preamble  for  ADS-B,  shown  in  Figure  13,  is  8  /is  in  duration.  It  has  4 


pulses,  with  each  pulse  width  the  same  .5  /is  as  that  of  a  pulse  from  the  ADS-B 


data  block. 
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Figure  13.  PPM  structure  of  ADS-B  preamble  and  data  block  [21]. 


Normally,  a  matched  hlter  could  be  used  to  correlate  the  incoming  signal  with 
the  preamble  template.  The  discrete  form  of  a  matched  hlter  is  shown  in  Equation 
4,  given  a  preamble  of  length  K  samples,  where  x[k]  is  the  value  of  the  kth  previous 
sample,  h[n  —  k]  is  the  fcth  coefhcient  in  the  reverse  impulse  response  of  the  dis¬ 
cretized  preamble  template,  and  y[n]  is  the  correlation  value  at  sample  n.  In  this 
format,  K  =  T  *  Fg  where  T  is  the  length  of  the  preamble  in  seconds  and  Fg  is  the 
sampling  rate. 

K 

y[n]  =  ^  h[n  —  k]x[k]  (4) 

k=0 

The  downsampled  sampling  rate  used  for  the  SADS-B  system  is  10  MS/s,  as  dis¬ 
cussed  in  Section  3.3,  so  h[n  —  k]  would  consist  of  80  coefficients,  the  graph  of  which 
is  horizontally  mirrored  against  the  preamble.  The  preamble  detector  would  trigger 
the  start  of  the  signal,  Ugtart  where  y[n\  is  at  its  local  maximum  above  a  threshold 
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correlation  value  C,  according  to  Equation  5. 


?^start  =  wliere  y[n]  >  C  (5) 

In  the  case  of  this  preamble,  as  shown  in  Figure  14,  each  of  the  0.5  ps  pulses  would 
have  coefficients  with  a  value  of  1.  As  this  is  a  PPM  signal,  all  other  positions  are 
“off”  and  would  have  coefficients  with  a  value  of  0. 


0.5  ys  2  MS  3  ys 

Figure  14.  Timing  of  ADS-B  preamble  pulses. 

However,  the  use  of  a  matched  hlter  breaks  down  when  using  any  zero-valued 
coefficients.  In  this  case,  3/4  of  the  coefficients  are  zero,  and  only  1/4  of  the  avail¬ 
able  samples  would  provide  input  to  the  correlation  value.  This  results  in  false  de¬ 
tections,  as  any  received  energy  between  1070-1110  MHz  for  5  ps  would  appear  as  a 
match.  To  correct  for  this,  all  coefficients  where  h[i]  =  0  coefficients  are  converted 
to  h[i]  =  —1.  This  more  correctly  utilizes  the  negative  spaces  between  pulses  to 
assist  in  the  proper  rejection  of  false  preambles. 

A  second  consideration  for  the  modihed  matched  hlter  design  is  scaling.  While 
a  clean  signal  with  high  signal-to-noise  ratio  (SNR)  (dehned  as  Eh/No)  works  well 
with  the  modihed  matched  hlter,  there  is  also  a  high  correlation  value  at  the  tail 
of  the  ADS-B  signal  itself,  in  some  cases.  The  worst  possible  scenario  is  shown 
in  Figure  15,  where  the  hlter  aligns  with  the  end  of  an  ADS-B  signal  ending  in 
[...,1,1,X,0,0],  with  X  representing  either  a  ”1”  or  a  ”0”.  Both  cases  are  shown. 

These  bits  are  part  of  the  Parity/Interrogator  Identity  (PI)  held  in  a  DF-17 
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Figure  15.  Worst  case  alignment  of  preamble  with  signal  for  a  matched  filter. 

message,  which  is  a  24-bit  CRC.  As  such,  each  of  the  last  5  bits  are  then  uniformly 
random  between  0  and  1.  The  probability  that  [1,1,X,0,0]  are  the  last  5  bits  of  any 
given  ADS-B  extended  squitter  (1090ES)  message  is  p  =  —  =  6.25%  To  be  prob¬ 
lematic,  this  situation  must  have  occurred  when  the  proper  preamble  was  not  de¬ 
tected.  ADS-B  has  no  channel  access  control,  such  as  Time  Division  Multiple  Ac¬ 
cess  (TDMA)  or  Frequency  Division  Multiple  Access  (FDMA),  built  in  to  the  pro¬ 
tocol,  nor  is  there  any  collision  detection.  Therefore,  the  likelihood  of  interference 
during  a  preamble  but  not  during  the  end  of  a  signal  is  non-negligible. 

A  heuristic  to  account  for  this  expected  occurrence  is  to  adjust  the  threshold 
value  C.  A  high  threshold  value  C  would  result  in  more  of  these  occurrences  being 
rejected,  but  also  falsely  rejects  more  low-SNR  preambles.  The  inverse  would  be 
true  in  low  threshold  value  C. 

An  alternative  approach  is  to  increase  the  penalty  for  received  signal  power  in 
the  null  (zero  power  or  “off”)  regions  of  the  preamble  template  shown  in  Figure  14. 
In  other  words,  only  scaling  the  negative  coefficients  by  a  penalty  factor  a  and  leav¬ 
ing  the  positive  coefficients  as  -|-1,  resulting  in  the  modihed  correlation  Equation 
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6. 


K 

y[n]  =  E  {a{h[n  —  A;]  —  1)  +  l)x[k]  (6) 

k=0 

A  consideration  for  setting  the  valne  of  a  in  the  preamble  detector  for  SADS-B 
design  is  the  worst  case  scenario  for  a  matched  hlter,  shown  in  Figure  15,  where  4 
pulses  correctly  align  with  the  positive  coefficients  in  h[n  —  k]  while  1  pulse  is  in  the 
null  region.  Even  when  using  -1  coefficients  for  the  null  regions  would  result  in  a 
strong  correlation  for  such  a  scenario.  However,  if  using  a  penalty  factor  set  a  >  4, 
the  single  pulse  in  the  null  region  would  negate  the  otherwise  strong  correlation 
value  allowing  a  correct  rejection  of  the  false  preamble. 


The  design  utilizes  a  pipelined  FIR  hlter,  with  a  generic  design  as  shown  in 
Figure  16.  In  larger  pipelined  FIR  hlter  designs,  the  total  latency  from  multiplying 
and  adding  may  be  too  great  for  the  clock  rate.  Given  the  sampling  rate,  there  is 
an  80-sample  window  for  preamble  correlation,  which  equates  to  an  80-order  FIR 
hlter.  Running  on  the  USRP™  XSlO’s  200  MHz  clock,  it  is  not  possible  to  complete 
a  multiply  operation  and  80  adds  in  a  single  clock  cycle. 

In  general,  additional  registers  may  be  added  in  a  FIR  design  between  some 
registers  and  combinational  adders,  as  in  Figure  17,  or  by  converting  the  adder 
structure  from  linear  to  a  hierarchical,  or  chain-out,  design.  The  design  for  the 


24 


preamble  correlator  uses  a  chain-out  design,  as  shown  in  Figure  18,  with  the  ad¬ 
dition  of  registers  (not  shown)  between  each  level  of  the  hierarchy  to  meet  FPGA 
timing  constraints. 


Figure  18.  Pipelined  FIR  chain-out  design  used  for  correlator  and  demodulator. 
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3.6  PPM  Demodulation 


In  the  demodulation  step,  a  simple  integrate  and  dump  FIR  filter  is  used,  also 
according  to  the  diagram  in  Figure  18,  with  +1  and  -1  coefficients  according  to  the 
‘0’  PPM  bit  with  the  pulse  in  the  hrst  half  of  the  bit  frame.  The  demodulated  bit 
is  simply  the  most  signihcant  bit  (MSB)  of  the  resulting  signed  Yout  value.  As  a 
result  of  only  using  the  center  3  values  of  each  pulse  width  (as  discussed  in  Section 
3.4),  the  coefficients  for  this  FIR  hlter  are  [0,-l,-l,-l,0,0,l,l,l,0]. 

3.7  Packetization  and  CRC  Validation 

In  the  SADS-B  Encryption  Module,  the  packetizer  occurs  immediately  follow¬ 
ing  the  PPM  demodulator.  It  consists  of  a  112-bit  buffer,  which  shifts  in  bits  as 
they  are  output  from  the  demodulator,  at  a  rate  of  1  Mb/s  or  once  every  10  sam¬ 
ples. 

As  the  inputs  are  shifted  in,  they  are  also  input  into  a  CRC  validation  compo¬ 
nent,  which  is  an  instantiation  of  the  serial  version  of  the  Ultimate  CRC  (UCRC) 
intellectual  property  (IP)  Core  [5].  UCRC  is  initialized  during  synthesis  with  the 
CRC-24  polynomial  in  Equation  7,  coming  from  the  ADS-B  specihcation  [21]. 

P{x)  =  -I-  -1-  -1-  x^°  -t-  x^®  -1-  x^®  -1-  x^^  +  x^®  -1-  x^®  -1-  x^^  +  x^  (7) 

Each  time  a  sample  is  shifted  into  UCRC,  the  computed  CRC  remainder  is  up¬ 
dated.  When  the  value  of  the  remainder  is  0,  the  match_o  signal  of  UCRC  is  set 
high,  indicating  the  CRC  matches.  An  output  register  in  the  packetizer  is  updated 
whenever  match_o  is  set  high.  Then  the  output  valid  signal  in  the  packetizer  turns 
is  set  high  for  a  clock  enable  period,  enabling  the  next  component,  the  FFX  encryp- 
tor. 
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3.8  FFX  Encryption 


The  encryption  design  implements  the  FFX-A2  algorithm  according  to  the  pa¬ 
rameters  radix=2,  length=104,  method=2,  split=52,  ronnds=12,  according  to  the 
parameters  nsed  in  Finke  [11].  It  does  so  using  a  fully-pipelined  implementation, 
in  contrast  with  an  iterative  looping  version  in  previous  research  [1] .  This  has  a 
greater  impact  on  decryption  and  is  discussed  in  more  detail  in  Section  3.9. 

As  a  valid  packet  sample  is  received  from  the  packetizer,  as  shown  in  Figure  11 
on  page  20,  it  is  broken  into  the  header  bits  (the  hrst  8  bits:  the  Downlink  Format 
(DF)  and  Capability  (CA)  helds),  and  the  encryption  plaintext  (the  remaining  104 
bits). 

The  header  is  passed  around  the  encryption  module  unchanged  using  a  delay 
buffer  with  8-bit  width  and  equal  in  length  to  the  number  of  clock  cycles  required 
to  complete  an  encryption.  The  output  of  the  header  delay  buffer  is  passed  directly 
into  the  modulator  component. 

Internal  to  the  FFX  encryption  component,  there  are  layers  of  similar  delay 
buffers.  Each  round  of  the  Feistel  structure  (recall  Figure  3  from  page  10)  con¬ 
sists  of  a  one  way  function.  The  function  is  detailed  in  Algorithm  1.  There 
are  two  AES  [4]  rounds  (yielding  X  and  then  Y),  according  to  the  F^  algorithm. 
The  AES  core  utilized  was  designed  by  Pranav  Patel  of  the  Air  Force  Institute  of 
Technology  and  was  verihed  during  previous  research  [16].  Because  of  the  pipelined 
structure,  a  delay  buffer  is  required  to  keep  Q  available  until  the  hrst  encryption 
completes,  generating  P‘.  Additionally,  this  structure  also  requires  24  AES  cores 
(2  per  round)  across  the  given  the  12-round  implementation.  Consequently,  with 
all  the  other  FPGA  components  involved  in  prototyping  an  SADS-B  system,  this 
structure  requires  more  resources  than  the  Kintex-7  has  available  (the  initial  design 
overmapped  the  FPGA  by  7%.  The  following  optimization  is  thus  implemented  to 
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reduce  the  number  of  required  cores  to  13  from  24.  The  hrst  AES  operation  in  each 
round  is  identical,  effectively  reproducing  P‘  every  round.  Therefore,  the  hrst  round 
will  produce  P‘  and  provide  it  as  an  output  to  each  subsequent  round,  as  shown  in 
Figure  19.  Note  that  the  d  block  is  a  delay  buffer  for  Q. 


P 

Q 


Y 


P' 


Figure  19.  First  round  of  FFX  Encryption  in  the  unrolled  design. 


Each  subsequent  round  is  then  altered  to  take  in  an  extra  P‘  input,  allowing 
11  out  of  the  12  instances  of  P^  to  have  only  one  AES  core,  as  shown  in  Figure  20. 
This  has  the  added  beneht  of  eliminating  the  need  for  delay  buffers  inside  P^  in 
other  rounds,  and  also  reduces  the  length  of  other  delay  buffers  across  the  entire 
design. 


P' 


Q 


-►  Y 


Figure  20.  Other  rounds  of  FFX  Encryption  in  the  unrolled  design. 


Given  the  unrolled  and  fully  pipelined  structure  of  the  SADS-B  modules,  delay 
buffers  are  used  in  each  round  of  FFX  according  to  the  block  labeled  d  in  Figure 
21.  The  hgure  highlights  the  operation  of  two  rounds  of  encryption  in  the  design. 


out  of  twelve. 


Figure  21.  Two  example  rounds  of  FFX  Encryption. 

3.9  FFX  Decryption 

One  benefit  of  utilizing  a  Feistel  structure  in  an  encryption  scheme  is  the  com¬ 
mon  design  for  encryption  and  decryption.  In  the  case  of  FFX  as  implemented  for 
ADS-B,  there  is  only  one  small  adjustment  that  needs  to  be  made.  The  design  is 
identical  to  that  described  in  Section  3.8,  except  that  n  =  (12  —  i)  instead  of  n  =  i 
for  the  Ffc  function  in  a  given  encryption  round,  inputs  C\\B  instead  of  A||i?,  and 
outputs  i?||A.  All  as  shown  in  the  decryption  diagram  in  Figure  22. 

The  fully  pipelined  aspect  of  the  overall  design  becomes  especially  important 
for  decryption.  In  the  SADS-B  Decryption  Module,  the  packetizer  cannot  perform 
CRC  validation,  as  the  bit  stream  is  encrypted,  including  the  parity  field  containing 
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Figure  22.  Two  example  rounds  of  FFX  Decryption. 

the  CRC.  Therefore,  every  valid  sample  from  the  PPM  demodulator  is  shifted  into 
the  packetizer,  which  updates  its  112-bit  output  signal  and  pulses  the  output  valid 
signal  for  one  clock  cycle.  Therefore,  every  sample  (bit)  from  the  PPM  Demodu¬ 
lator  results  in  a  decryption,  which  could  sometimes  be  from  overlapping  signals. 
Only  after  the  decryption  is  performed  on  any  given  112-bit  sequence  can  the  CRC 
validation  step  occur,  as  depicted  in  Figure  12  on  page  20. 
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3.10  PPM  Modulation 


3.10.1  Encryption  Version. 

PPM  modulation  in  the  SADS-B  Encryption  Module  is  straight  forward.  Us¬ 
ing  Figure  12  as  a  reference,  when  the  i_rdy  signal  is  high,  the  112-bit  (encrypted) 
i_data  packet  is  stored  in  a  112-bit  vector.  Then,  on  each  subsequent  clock  enable 
(10  MS/s),  the  bits  are  shifted  out  in  order  (DF  bits  hrst),  converted  to  I  and  Q 
data  in  o_I  and  o_Q,  respectively,  while  the  o_valid  signal  is  set  high  for  one  clock 
enable  period.  Because  the  PPM  signal  is  phase  agnostic,  each  pulse  I  and  Q  are 
set  to  25%  of  the  dynamic  range,  2^®/4  =  0a;(4000)  and  a  negative  space  is  set  to 
0a:(0000). 

The  modulation  begins  with  a  proper  preamble,  and  o_valid  set  high.  Given 
the  10  MS/s  sample,  there  are  80  I  and  Q  samples  generated  before  any  actual  bits 
are  modulated  from  the  112-bit  vector.  There  are  4  sets  of  5-sample  pulses  that 
are  modulated,  according  to  the  offsets  shown  in  Figure  14  on  page  22.  After  the 
preamble  has  been  modulated,  each  data  bit  (starting  with  the  DF-17  header)  is 
then  converted  to  a  10-sample  PPM  frame  using  a  counter  with  simple  logic.  When 
the  last  bit  has  been  modulated,  o_valid  returns  low. 

3.10.2  Decryption  Version. 

In  the  SADS-B  Decryption  Module,  the  additional  step  of  CRC  validation  oc¬ 
curs  before  the  modulation  into  I  and  Q  occurs.  Again,  using  an  instance  of  the 
serial  UCRC  component,  the  CRC  value  is  checked  as  the  bits  are  shifted  out  of  the 
112-bit  input  vector  into  the  UCRC  component  [5].  Simultaneously,  they  are  also 
shifted  into  a  second  112-bit  vector,  which  acts  as  an  output  buffer.  When  the  last 
sample  is  shifted  into  the  UCRC  checker,  the  o_match  signal  from  UCRC  should  go 
high,  indicating  a  CRC  match.  If  this  occurs  (and  the  packet  has  been  validated). 
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the  output  buffer  will  empty  as  it  is  converted  into  to  the  10  MS/s  modulation  sig¬ 
nal  described  above  in  Section  3.10.1. 

3.11  ADS-B  Selector 

The  ADS-B  Selector  component  in  both  the  SADS-B  Encryption  Module  and 
Decryption  Module  is  not  an  instantiated  component  like  the  other  functional  blocks 
shown  in  Figures  11  and  12  from  page  20.  It  consists  of  a  simple  buffer  for  the  in¬ 
put  I,  Q,  and  strobe  signals,  equal  in  length  (cycle  count)  to  the  rest  of  the  design. 
This  allows  the  input  signal  to  be  seamlessly  passed  through  the  SADS-B  module 
for  all  cases  where  i_valid  no  signal  modification  is  occurring. 
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IV.  Results  and  Analysis 


This  chapter  details  the  process  used  to  verify  and  characterize  the  SADS-B 
prototype,  according  to  accuracy,  latency,  and  FPGA  resource  utilization.  It  then 
presents  and  evaluates  the  results. 


4.1  Verification  Methodology 


From  the  research  goals  outlined  in  Section  1.3,  there  are  two  aspects  of  verih- 
cation  that  were  accomplished:  component-level  and  system-level. 


4.1.1  Component  Verification. 


Each  major  component  is  verihed  in  several  steps  along  the  way  to  verifying 
the  system  as  a  whole. 


Algorithm 


VHDL 

Design 


Hardware 
&  Timing 


Figure  23.  Component  verihcation  process. 
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The  diagram  in  Figure  23  depicts  the  overall  process  by  which  the  compo¬ 
nents  were  verihed.  At  the  algorithm  level,  an  ideal  stimulus  vector  is  generated 
(e.g.  an  ideal  ADS-B  message  or  PPM  signal)  in  MATLAB®.  The  stimulus  vector 
is  used  as  a  test  input  for  the  component  under  test  (CUT).  The  output  from  the 
MATLAB®  instantiation  of  that  component  (e.g.  a  preamble  detector)  is  another 
vector  (e.g.  the  ADS-B  data  stream).  The  output  vector  is  then  be  plotted  or  oth¬ 
erwise  used  to  verify  the  correctness  of  the  CUT  design  at  the  algorithm  level. 

Second,  the  stimulus  vector  is  used  to  generate  the  stimulus  hie  for  the  design 
verihcation.  The  stimulus  hie  is  a  text  hie  that  contains  a  single  numerical  data 
sample  on  each  line.  Additionally,  a  VHDL  test  bench  hie  is  also  needed  to  per¬ 
form  three  functions:  (1)  provide  simulated  input  to  the  hardware,  (2)  instantiate 
the  CUT,  and  (3)  record  the  output  of  the  simulation.  The  input  and  output  oc¬ 
cur  by  means  of  simulation-only  VHDL  components.  These  components,  the  data 
source  and  data  sink,  read  input  from  a  specihed  hie  or  write  output  to  a  specihed 
hie,  respectively.  Active-HDL®  or  ModelSim®  use  the  test  bench  design  to  simu¬ 
late  the  operation  of  the  CUT.  An  example  of  a  stimulus  hie  would  be  a  set  of  [I,Q] 
data  inputs  to  the  preamble  detector  or  PPM  demodulator.  The  data  source  reads 
one  line  from  the  stimulus  hie  (typically  16-bit  integer  format),  and  supplies  the 
data  as  input  to  the  CUT,  once  per  clock  cycle.  The  data  sink  converts  the  output 
of  the  CUT  to  a  numerical  value,  and  writes  it  to  a  hie,  once  per  simulated  clock 
cycle. 

Third,  the  stimulus  vector  is  used  to  drive  the  signal  generator  for  hardware 
and  timing  verihcation.  For  testing  purposes,  an  additional  Xilinx  ISE  ChipScope® 
Pro  HDL  component  is  added  into  the  design  to  monitor  signals  of  interest  to  mon¬ 
itor  the  operation  of  the  CUT.  As  described  in  Section  2.6,  ChipScope®  Pro  pro¬ 
vides  a  mechanism  to  capture  real-time  data  signals  to  an  attached  PC  for  static 
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analysis.  Alternatively,  the  signals  may  be  verified  using  data  capture  tools  avail¬ 
able  via  the  USRP^^  top  level  code,  using  the  GNU  Radio  command  line  tools. 

After  compilation  of  the  design  in  Xilinx  ISE,  the  design  is  programmed  onto  the 
FPGA  on  the  X310.  Using  MATLAB®,  the  stimulus  vector  is  uploaded  to  the 
Keysight  N5182B  signal  generator  using  the  Advanced  Gonfiguration  and  Power 
Interface  (AGPI)  interface  over  the  network.  Depending  on  the  method  of  capture, 
either  the  Xilinx  ISE  Analyzer  tool  is  used  to  control  and  retrieve  data  from  the 
GhipScope®  Pro  component,  or  the  files  captured  via  GNU  Radio  are  loaded  in 
MATLAB®  for  static  analysis. 

Lastly,  the  outputs  verification  phases  are  compared  to  each  other  and/or  ground 
truth  information  to  verify  functional  correctness  of  the  GUT. 

4.1.2  System  Verification. 

Encryption. 


Plaintext 


Ciphertext 


Figure  24.  End-to-end  verification  in  encryption  mode. 

System  verification  for  SADS-B  in  encryption  mode  is  accomplished  using  the 
previously  captured  ADS-B  signals  from  the  Aerofiex  IFR  6000.  The  signals  have 
approximately  80  /is  of  quiet  surrounding  the  signal.  Figure  25  shows  a  plot  of  the 
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signal  power  for  one  of  the  Aeroflex  ADS-B  signals. 


Aeroflex  IFR  6000  ADS-B  Signal 


0  0.2  0.4  0.6  0.8  1  1.2  1.4  1.6  1.8  2 


Time  (s)  X 10’'* 

Figure  25.  Example  Aeroflex  IFR  6000  signal. 

Using  an  ACPI  interface  over  a  TCP/IP  connection,  MATLAB®  is  used  to 
upload  one  of  the  signals  to  the  Keysight  N5182B  signal  generator.  The  signal  gen¬ 
erator  is  then  conhgured  to  continuously  repeat  the  signal,  which  simplihes  data 
collection.  With  the  repeating  signal  approximately  200  ps  in  length,  any  data  cap¬ 
ture  of  at  least  400  ps  will  contain  at  least  one  complete  ADS-B  message. 

In  correct  operation,  the  SADS-B  prototype  would  receive  the  ADS-B  Out  sig¬ 
nal  from  the  signal  generator  and  transmit  the  SADS-B  Out  signal.  The  next  de¬ 
vice  in  the  chain  is  a  second  USRP™  acting  as  a  SDR  conhgured  (using  GNU  Ra¬ 
dio)  according  to  the  diagram  shown  in  Figure  5.  It  is  set  as  a  simple  receiver,  sam¬ 
pling  as  10  MS/s,  centered  on  1090  MHz.  The  data  is  captured  on  the  controlling 
PC.  The  function  of  this  USRP^”  is  to  capture  the  SADS-B  Out  signal  for  verihca- 
tion  through  static  analysis  in  MATLAB®.  The  received  data  is  in  an  interleaved 
[I,Q]  format,  each  of  which  are  32  bit  precision  hoating  point  numbers. 

The  next  step  in  MATLAB®  is  to  setup  the  data  for  analysis.  This  consists  of 
de-interleaving  the  [I,Q]  data,  plotting,  manual  inspecting  the  plot  for  the  signal. 
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and  cropping  the  signal  down.  The  signal  can  then  be  analyzed  by  using  the  PPM 
Demodulator  MATLAB®  model  to  retrieve  the  bits. 

The  recovered  bits  are  compared  with  known  ciphertext  (determined  previously 
when  verifying  the  FFX  Encryptor  component  in  Section  4.2.4. 

Decryption. 


Ciphertext 


Plaintext 


Figure  26.  End-to-end  verihcation  in  decryption  mode. 

A  similar  process  is  followed  for  verihcation  of  the  SADS-B  prototype  in  de¬ 
cryption  mode,  with  a  few  modihcations  as  depicted  in  Figure  26. 

Specihcally,  the  signal  just  captured  during  the  Encryption  test  is  used  to  drive 
the  N5182B  vector  signal  generator.  In  the  hnal  step,  instead  of  comparing  with 
the  known  ciphertext,  a  comparison  is  made  with  known  plaintext. 

4.2  Component  Verification  Results 

Several  captured  hies  from  an  Aerohex  IFR  6000  are  used  to  verify  the  pream¬ 
ble  detector.  The  captures  are  baseband  I  and  Q  data  samples,  saved  in  comma 
separated  value  (CSV)  format,  at  a  a  sample  rate  of  50  MS/s.  The  ADS-B  values 
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used  to  create  the  data  are  known,  providing  the  basis  for  comparison  throughout 
verihcation. 

4.2.1  Preamble  Detection. 

Modeling  and  Simulation. 

For  the  MATLAB®  simulation,  the  captured  hies  are  loaded,  downsampled  to 
10  MS/s,  and  quantized  to  16-bit  samples  using  the  MATLAB®  Communications 
System  Toolbox^^  function  fi.  The  I  and  Q  samples  are  combined  into  received 
signal  power,  P  =  P  +  Q^. 


Aeroflex  IFR  6000  ADS-B  Signal 


Preamble  Correlation  Values 


Figure  27.  MATLAB®  results  for  preamble  detection  with  a  =  5. 

The  hrst  plot  in  Figure  27  shows  the  resulting  waveform  plot  of  power  over 
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time.  The  second  plot  in  Figure  27  shows  the  correlation  coefficient  y[n\  (as  dis¬ 
cussed  in  Section  3.5)  over  time.  The  first  local  maximum  aligns  correctly  to  the 
signal  start  at  t  =  3.08  *  10“"^  s,  with  a  correlation  value  of  y[n]  =  5.61  *  10“^. 
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Hardware  Simulation. 


In  the  case  of  the  preamble  detection,  there  are  two  stimulus  hies  created  by 
the  MATLAB®  simulation.  The  hies  written  contain  the  downsampled  I  and  Q 
data  (10  MS/s),  consisting  of  one  sample  per  line  in  integer  representation  of  the 
signed  16-bit  samples. 


Figure  28.  Hardware  simulation  results  for  preamble  detection  with  a  =  5. 


Figure  28  shows  the  results  of  the  simulation,  via  a  screenshot  of  the  simula¬ 
tion  interface  in  the  Active  HDL  program.  It  shows  the  output  valid  signal  o_valid 
is  correctly  set  high  and  low  corresponding  to  the  presence  of  the  ADS-B  data  sig¬ 
nal,  for  a  period  of  exactly  112  /rs.  Additionally,  it  shows  the  timestamp  of  the  ris¬ 
ing  edge  of  o_valid  as  29,050  ns,  which  gives  context  to  Figure  29. 


13  *r  f_corrl2] 


0  -o  o_pwr 


-o  0  valid 


Clisot  1 


Figure  29.  Hardware  simulation  results  zoomed  in  on  preamble. 
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In  Figure  29,  the  8  /is  (8000  ns)  preamble  (shown  in  o_pwr)  is  exactly  preced¬ 
ing  the  sample  that  is  classified  as  Ustart,  the  beginning  of  the  ADS-B  data  signal. 
The  o_valid  also  is  set  high  in  alignment  with  the  hrst  sample  of  the  data  sig¬ 
nal  and  the  peak  correlation  coefficient  y[n]  (shown  as  f_corr[2]).  The  output  of 
the  synchronizer  component  during  hardware  simulation  in  Active-HDL®  is  a  1120 
sample  text  file,  where  the  first  sample  in  the  hie  is  the  hrst  sample  of  the  hrst  data 
bit  of  the  ADS-B  signal. 

4.2.2  PPM  Demodulation. 

The  demodulator  only  reads  inputs  when  o_valid  from  the  synchronizer  is  set 
high.  Recalling  the  top  plot  from  Figure  27,  the  data  input  read  by  the  demodula¬ 
tor  is  essentially  a  shifted  and  clipped  version,  shown  in  Figure  30. 


Synchronized  Aeroflex  IFR  6000  ADS-B  Signal 


Figure  30.  Plot  of  synchronizer  output  as  received  into  the  demodulator. 


Modeling  and  Simulation. 

The  demodulation  output  should  be  the  112  bits  that  this  PPM  signal  rep¬ 
resents.  For  verihcation  in  MATLAB®,  the  stimulus  vector  is  the  1120  samples 
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as  plotted  in  Figure  30  and  the  output  is  a  112  bit  vector.  In  this  case,  the  sim¬ 
plest  mechanism  to  verify  the  bits  are  correct,  aside  from  manual  inspection,  is 
to  parse  the  data  values  into  the  respective  ADS-B  helds  and  compare  with  the 
ground  truth  data.  However,  the  PI  held  containing  the  24-bit  CRC  was  not  ex¬ 
plicitly  provided  as  input  to  the  Aerohex  IFR  6000,  but  the  ground  truth  for  it  is 
calculated  from  the  hrst  88  bits  of  the  message.  The  Communications  System  Tool¬ 
box™  in  MATLAB®  provides  CRC  utilities,  which  are  utilized  for  this  purpose. 

The  plot_sim_sync_output  .m  MATLAB®  script  is  used  to  perform  the  parsing 
and  CRC  calculation,  then  compare  the  results. 


»  plot_3im_3ync_output; 

df  =  17,  ca  =6,  aa  =  A92492,  me  =  48050763089406 

message  being  tested:  10001110101010010010010010010010010010000000010111010111 

01100011110010001001010011010110 

message  with  checksum  computed:  10001110101010010010010010010010010010000000010111010111 

01100011110010001001010011010110110100000010100000111011 
message  as  received/ interpreted:  10001110101010010010010010010010010010000000010111010111 

01100011110010001001010011010110110100000010100000111011 
bits  should  be  zero  if  no  error:  0 

Figure  31.  Verihcation  output  of  PPM  demodulation  in  MATLAB®. 


The  printout  from  the  function  is  shown  in  Figure  31.  As  shown,  the  computed 
CRC  values  match  the  demodulated  bits.  Additionally,  the  message  data  matches 
known  values. 


Hardware  Simulation. 

The  hardware  simulation  for  demodulation  verihcation  is  performed  in  ModelSim®, 
using  the  1120-sample  stimulus  hie  generated  as  output  during  synchronizer  verih¬ 
cation.  The  output  and  enable  signals  are  verihed  for  correct  timing.  Additionally, 
the  hnal  output  is  verihed  through  static  analysis  using  a  MATLAB®  script. 

Figure  32  shows  the  results  of  the  ModelSim®  simulation.  From  the  hgure, 
the  period  of  the  1  /is  (1000000  ps)  is  shown  between  samples.  Also,  the  output 
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t/u_ppm_demodulator/o_data_bit 

0 

ryptAj_ppni_demodulator/o_valid 

1 

j_ppm_demodulator/f_acajm_10 

1887917618 

Now 

100000000  ps 

Cursor  1 

14802500  ps 

Cursor  2 

13802500  ps 

Figure  32.  ModelSim®  10.4  screenshot  of  demodulator  verification. 


samples  are  aligned  with  the  peaks  and  valleys  in  the  signal,  indicating  a  correctly 
implemented  pipeline  structure. 

The  output  file  captured_demod_signal.txt  is  analyzed  using  a  similar  script 
from  modeling  and  simulation  verihcation.  The  plot_sim_demod_output  .m  per¬ 
forms  essentially  the  same  steps  as  the  plot_siin_sync_output  .m  previously  used, 
only  instead  of  reading  the  input  from  a  MATLAB®  vector,  the  input  is  read  in 
from  captured_demod_signal.txt  hie  as  output  from  the  demodulator.  The  out¬ 
put  conhrms  the  number  of  bits  in  addition  to  the  correctness  of  the  bits,  all  shown 
in  Figure  33. 


»  plot_3im_demod_output 

file  captured_3iia_demod_3ignal_l.txt  i3  length  112 
df  =  17,  ca  =6,  aa  =  A92492,  me  =  4805D763C894D6 

me33age  being  teated:  10001110101010010010010010010010010010000000010111010111 

01100011110010001001010011010110 

message  with  checicsum  computed:  10001110101010010010010010010010010010000000010111010111 

01100011110010001001010011010110110100000010100000111011 
message  as  received/ interpreted:  10001110101010010010010010010010010010000000010111010111 

01100011110010001001010011010110110100000010100000111011 
bits  should  be  zero  if  no  error:  0 

Figure  33.  Verihcation  of  demodulator  hardware  design  output  using  MATLAB®. 
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4.2.3  Packetization  &  CRC  Validation. 


Verification  for  the  packetizer  component  is  focused  on  hardware  implementa¬ 
tion,  as  there  is  a  readily  available  CRC  verihcation  mechanism  using  the  MATLAB® 
Communications  System  Toolbox^^  and  the  correct  implementation  of  packetiza¬ 
tion  is  essentially  a  hardware  timing  problem.  Therefore,  rather  than  generate  an 
explicit  stimulus  vector  to  verify  the  packetizer  component,  the  test  bench  for  hard¬ 
ware  verihcation  consists  of  reusing  the  previous  test  bench  for  PPM  demodulation, 
with  the  outputs  wired  as  the  inputs  for  the  packetizer. 


Figure  34.  ModelSim®  10.4  screenshot  of  packetizer  verihcation. 


Figure  34  shows  the  ModelSim®  results  for  the  described  test  bench.  As  the 
last  sample  is  output  according  to  the  demodulator’s  o_valid  signal,  the  CRC 
matches  (shown  by  w_matched_crc)  and  the  output  is  correctly  loaded  into  the 
output  register,  o_data.  The  message  in  the  test  case  is  known,  including  the  CRC 
bits,  which  match  the  output  shown. 

4.2.4  FFX  Encryption  and  Decryption. 

There  are  no  published  test  vectors  for  for  verifying  FFX  encryption  as  there 
are  for  other  standards  such  as  AES.  However,  many  plaintext-ciphertext  pairs  were 
generated  by  Finke  in  the  evaluation  of  FFX  for  use  in  securing  ADS-B  during  pre¬ 
vious  research  [11].  These  plaintext-ciphertext  pairs  will  serve  as  the  basis  for  veri¬ 
hcation  for  the  implementation  of  FFX.  As  such,  the  verihcation  for  the  encryption 
and  decryption  components  will  be  performend  in  hardware  simulation. 
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1 12R_bytes_l.txt  -  Notepad 


FiIf  Frlit  Pnrm^t  Hcin 


3bldelc7a84a3ed556585a93b5| 

13b53e3b564ad558a85ac71del 

585aada8elc74ab5d51d3b563e 

C72c5alda83bel584a3eb556d5 


i  ^  1 

^Jel^_bytes_l.txt  -  Notepa^ 

File  Edit  Format  View  Help 


c0ef79c406c65cf7GefeO7393a| 

aG21c2a9ad47129f6G9c5b4a99 

57d7400b945834ald72e6blf8c 

Ia9c059c03fl7b91fa5579c09a 


Figure  35.  Screenshot  of  Finke  test  plaintext  and  ciphertext  hies  [11]. 


Figure  35  shows  an  example  plaintext /ciphertext  pair  that  is  used  to  verify  the 
SADS-B  encryption  and  decryption  components,  where  the  12R_bytes_l.txt  hie 
contains  the  plaintext  messages  and  el2R_bytes_l.txt  contains  the  corresponding 
ciphertext.  As  the  ADS-B  DF  and  CA  helds  are  not  encrypted,  they  are  not  shown 
in  the  hies.  The  encryption  key  for  the  test  hies  is  known  and  set  statically  prior  to 
simulation.  The  key  is  shown  in  Figure  36. 


CH'  . .  .FFX_erKTypt^_key 
D-J'  . . .  AJ_FFX_er)aypt/i_T 
J"  ...  _FFX_encrypt/i_dk 

{2B}... 

12 

0 

381... 

000... 

0 

Id 

7  [7E}  fl5 

:  he:  [;s: 

hE!  :d3: 

!'A6;  !'AE': 

^7  [le:  [ 

vs;  ;39:  [c 

- 

'  n 

O-J"  ...X_efKrypt^_p_text 

3B 

1DE:C7A3- 

A3ED5565 

i5A93E5 

_ 

O-'j.  . .  .rypt/o_dpher_text 
...aypt/o_cipher_rdy 

79C-4<36C6 

5CF7EEFEC' 

'’393A 

_ ^ _ 1 _ 1 _ 1 _ 

Figure  36.  Screenshot  of  encryption  component  in  ModelSim®. 


For  encryption  verihcation.  Figure  36  shows  the  plaintext  message  input  and 
the  corresponding  ciphertext  output,  aligned  to  the  clock  cycle  when  the  output 
valid  o_cipher_text_rdy  is  set  high.  The  input  and  output  match  the  known 
plaintext /ciphertext  pair. 

Similarly,  for  decryption.  Figure  37  shows  the  ciphertext  message  input  and  the 
corresponding  plaintext  output,  aligned  to  the  clock  cycle  when  the  output  valid 
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'u_FFX_decrypt^_dk 
'u_FFX_deaypt^_T 
'u_FFX_deaypt^_c_text 
‘u_FFX_deaypt/o_p_text 
'u_FFX_deaypt/o  _p_text_rdy 


fra— 


Figure  37.  Screenshot  of  decryption  component  in  ModelSim®. 


o_p_text_rdy  is  set  high. 


4.2.5  PPM  Modulation. 


-o  o_valid 
Cursor  1 


1 


*■ 


120  U5 


18250  nsl 

Figure  38.  Screenshot  of  full  modulation  signal  in  Active-HDL®. 


h 


As  with  PPM  demodulation,  the  verihcation  for  PPM  modulation  is  focused  on 
timing  implementation.  Figure  38  shows  the  full  signal  timing  of  the  output,  which 
is  aligned  to  the  output  valid  o_valid  signal.  Additionally,  the  period  of  the  signal 
is  correct  at  120  ps  (including  the  preamble).  Figure  39  shows  the  same  simulation, 
zoomed  in  on  the  preamble  to  verify  its  appropriate  timing  prior  to  bit  modulation. 
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Figure  39.  Screenshot  of  modulation  signal  in  Active-HDL®,  zoomed  on  preamble 
timing. 


4.3  Performance  Test  Methodology 

4.3.1  Evaluate  End-to-End  Latency. 

Latency  is  a  significant  factor  in  achieving  an  operationally  useful  prototype 
for  SADS-B.  Evaluation  of  the  end-to-end  latency  consists  of  measuring  the  opera¬ 
tional  latency  of  the  SADS-B  prototype  in  each  mode  (decrypt  and  encrypt)  follow¬ 
ing  the  successful  verihcation  of  the  system.  Because  the  design  is  fully  pipelined, 
the  longest  propagation  path  (in  units  of  clock  cycles)  can  be  determined  through 
static  VHDL  code  analysis.  Alternatively,  the  FPGA  component  latency  can  be 
measured  using  a  simulation  environment  as  well.  However,  this  does  not  account 
for  the  overhead  latency  of  the  signal  propagation  within  the  X310  before  and  after 
the  designed  SADS-B  module. 

Therefore,  an  additional  and  more  robust  measurement  of  operational  latency 
requires  the  use  of  a  dual  input  oscilloscope.  In  this  case,  a  Teledyne  LeCroy  Wave- 
Pro  760Zi-A  is  used,  according  to  the  setup  shown  in  Figure  40.  To  perform  the 
measurement,  the  signal  generator  is  setup  using  MATLAB®  to  generate  a  valid 
ADS-B  waveform  (previously  captured  from  an  Aeroflex  IFR  6000),  as  described  in 
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Section  4.1.2.  However,  the  primary  difference  in  this  case  is  the  N5182B  vector  sig¬ 
nal  generator  will  not  be  setup  in  a  repeating  mode.  Instead,  it  will  perform  a  sin¬ 
gle  playback  of  the  ADS-B  waveform  upon  a  trigger  button  being  manually  pressed 
on  the  signal  generator.  The  trigger  could  alternatively  be  set  through  an  ACPI 
commands  via  MATLAB®.  Before  playback,  the  oscilloscope  is  setup  to  trigger 
appropriate  on  the  input  ADS-B  preamble  reaching  a  specified  power  level.  Once 
triggered,  the  oscilloscope  captures  both  channels  at  40  GSPS.  The  data  is  then 
manually  saved  using  the  interface  on  oscilloscope  to  an  attached  USB  drive.  The 
results  are  evaluated  using  MATLAB®  plots  and  manually  inspection. 


Figure  40.  Test  setup  for  end-to-end  latency  measurement. 


The  data  collection  is  saved  to  a  local  file  on  the  oscilloscope,  off-loaded  to  a 
PC  and  plotted  using  MATLAB®.  Because  the  captures  are  synchronized,  the  la¬ 
tency  in  seconds  is  simply  a  At  =  As  x  Fg,  where  As  is  the  number  of  samples 
between  the  start  of  each  preamble  and  Fg  is  the  sample  rate  of  the  oscilloscope. 

The  process  is  repeated  for  each  mode  (encryption  and  decryption).  Finally, 
the  results  are  evaluated  against  the  threshold  latency  of  50ms  based  on  the  ADS-B 
specification  [21]. 
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4.3.2  Evaluate  Performance  of  SADS-B  Components. 


Demodulation  Error. 

Demodulation  is  evaluated  against  the  lower  limit  bit  error  rate  (BER)  for  a 
2-PPM  signal,  which  is  the  same  as  on-off  keying  (OOK)  and  shown  in  Equation  8. 

BER  >  i  (8) 

A  Monte  Carlo  simulation  is  performed  by  using  the  randn  in  MATLAB®  to 
generate  and  add  noise  to  a  random  stream  of  bits,  according  to  the  various  levels 
of  Eb/No,  the  SNR.  The  BER  for  the  implemented  algorithm  is  evaluated  against 
the  ideal  formula  curve  on  a  plot  of  SNR  vs.  BER. 

Preamble  Detection  Error. 

A  Monte  Carlo  simulation  is  used  to  evaluate  detection  performance,  using  two 
simulations.  The  hrst  simulation  evaluates  how  well  each  value  of  a  performs  when 
a  preamble  signal  is  present.  It  begins  with  an  ideal  preamble  signal  and  uses  the 
randn  function  within  MATLAB®  to  add  additive  white  Gaussian  noise  (AWGN) 
to  the  signal  to  a  specified  SNR.  Next,  the  resulting  signal  is  input  to  the  preamble 
detector  algorithm.  The  number  of  correct  detections  are  recorded.  This  is  repeated 
for  a  variety  of  settings  for  a.  The  false  negative  rate  (FNR)  is  then  used  to  evalu¬ 
ate  the  performance  across  different  settings  of  a. 

The  second  simulation  is  similar,  but  begins  with  a  half-matching  false  pream¬ 
ble.  The  false  preamble  is  a  signal  with  four  pulses  that  align  to  the  preamble  pulses. 
It  also  has  four  pulses  that  do  not  align.  This  is  similar  to  many  “8-bit  windows” 
PPM.  Visually,  the  two  general  cases  where  this  is  possible  are  shown  in  Figure  41. 

In  a  normal  ADS-B  signal,  this  bit  pattern  is  likely  to  occur  in  approximately 
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1  X  0  0  X  X  X 

Half-matching  8-bit  PPM  window 

:  Preamble  template 

Figure  41.  Preamble  template  aligning  with  8  bits  from  a  PPM  signal. 

12.5%  of  the  time.  It  will  either  occur  with  [1,1,X,0,0,X,X,X]  pattern  (as  discussed 
later  in  Section  3.5),  or  with  a  [0,0,X,X,1,1,X,X].  An  ‘X’  in  these  patterns  repre¬ 
sents  either  a  ‘1’  or  a  ‘O’,  and  are  where  a  pulse  is  placed  for  this  simulation.  Each 
of  these  events  have  approximately  ^  —  6.25%  chance  to  occur,  combining  to 

approximately  a  12.5%  of  either  of  them  occurring  in  any  given  8-bit  window  in  the 
ADS-B  PPM  signal. 

If  the  demodulation  results  correlate  with  ideal  BER  formula  given  by  Equa¬ 
tion  8,  then  Figure  42  will  approximate  the  minimum  Eh/No  required  to  receive  a 
signal  error-free  80%  of  the  time. 

Let  SNRfhr  be  the  threshold  value  of  Eb/No  determined  in  Figure  42.  The 
preamble  detection  results  will  be  used  to  determine  the  optimal  value  of  penalty 
factor  a  based  on  the  following  criteria: 

(1)  successful  detection  of  real  preambles  (TPR)  >  90%,  ^Eb/No  >  SNRthr 

(2)  successful  rejection  of  normal  ADS-B  signals  as  preambles  (TNR)  >  90%, 

yEb/No  >  SNRthr 
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1  - 
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1  ^  ^-E,/No 

2 

1.99*  10"^ 
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10  *logio  5.526  =  7.424dB 


Figure  42.  E^/Nq  that  will  be  allow  error-free  reception  80%  of  the  time. 


With  these  criteria  in  mind,  the  maximum  allowable  false  positive  rate  (FPR) 
(1-true  negative  rate  (TNR))  that  will  satisfy  condition  (2)  is  calculated  in  Figure 
43.  Therefore  a  correctly  implemented  preamble  detector  will  have  a  FPR  <  7.95  * 
10-3,  yEb/No  >  SNRthr. 


Let  P{EP)  be  the  probability  of  false  preamble  detection  across  a  112-bit  ADS- 
B  signal.  Let  P{HM)  be  the  probability  of  a  false  preamble  detection  during 
an  8-bit  ADS-B  signal  that  matches  one  of  the  templates  described  in  Section 


4.3.2. 


(1  -P(FP))(312-6) 

P(PP) 

P(PP) 

P(PP) 

P{HM) 

ERR 


90% 

1  - 

9.935  *  10“^ 
P{HM)  X  ERR 

2x  \  =  .125 
24 

9.935  *  10-^ 


.125 


=  7.95  *  10-3 


Figure  43.  ERR  that  will  allow  successful  rejection  90%  of  the  time. 
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4.4  Performance  Results 


4.4.1  Operational  Latency. 


Figure  44.  Timing  of  input  sample  for  SADS-B  encryption  module. 


Figure  44  shows  arrival  timing  of  the  first  preamble  sample  as  input  into  the 
SADS-B  encryption  module  from  the  DDC  on  the  FPGA.  Though  not  visible,  note 
that  this  time  is  aligned  with  the  rising  edge  of  the  clock  i_clk  when  the  clock  en¬ 
able  signal  i_clk_en  is  high. 


Figure  45.  Timing  of  input  sample  for  SADS-B  encryption  module. 


Figure  45  shows  the  output  timing  of  the  corresponding  output  preamble  sam- 
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pie  from  the  SADS-B  encryption  module  to  the  DUG  on  the  FPGA.  The  time  is 
aligned  with  the  rising  edge  of  i_clk  when  the  output  enable  signal  o_strobe  is 
high.  The  resulting  latency  of  the  SADS-B  module  is  144207500  -  19997500  ps  = 
124.21  /is  of  latency. 

4.4.2  Demodulation  Performance. 

Figure  46  shows  the  results  from  the  Monte  Garlo  simulation  of  the  PPM  De¬ 
modulator  component  of  the  SADS-B  Modules.  The  same  component  was  used  for 
encryption  and  decryption,  so  the  simulation  was  only  performed  once.  10,000,000 
randomly  generated  bits  (using  the  randi  MATLAB®  function)  were  converted  to 
their  ideal  PPM  signal,  with  a  pulse  value  of  \/2  -|-  \/2i,  across  the  number  of  sam¬ 
ples.  AWGN  was  added  to  each  sample,  according  to  a  specihed  Eh/No,  by  using 
the  randn  MATLAB®  function  and  scaling  it.  The  detection  algorithm  was  then 
used  to  determine  the  bit  value  of  the  PPM  signal  according  to  the  algorithm  dis¬ 
cussed  in  Section  3.6.  The  resulting  bit  was  compared  to  the  known  vector  and  the 
number  of  errors  was  recorded  for  that  particular  value  of  Eb/No.  The  results  show 
that  the  algorithm  performs  closely  to  the  ideal  BER  rate  for  a  2-PPM  signal. 

4.4.3  Preamble  Detection  Characteristics  and  Performance. 

With  the  demodulation  results  closely  correlating  to  ideal  2-PPM  BER,  the 
threshold  SNRthr  =  7A24dB  from  Section  4.3.2  can  be  used  as  an  approximation 
for  the  threshold  SNR  for  the  criteria  for  successful  preamble  detection.  Recalling 
these  criteria,  they  are: 

(1)  successful  detection  of  real  preambles  (TPR)  >  90%,  ^Eb/No  >  SNRthr 

(2)  successful  rejection  of  normal  ADS-B  signals  as  preambles  (TNR)  >  90%, 

yEb/No  >  SNRthr 
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PPM  Demodulator  Error  Results 


E^/No  (dB) 


Figure  46.  BER  results  of  Monte  Carlo  simulation. 


The  first  simulation  was  conducted  according  to  Section  4.3.2  and  used  1,000,000 
randomly  generated  samples  per  trial  run.  Each  sample  consists  of  an  ideal  PPM 
signal  with  AWGN  added  using  the  MATLAB®  randn  function,  scaled  to  achieve 
the  desired  value  of  Eb/No.  The  results  in  Figure  47  show  the  rate  at  which  valid 
preambles  are  succesfully  detected  (i.e.  the  true  positive  rate  (TPR))  based  on  a 
corresponding  value  of  Eb/NQ.  This  simulation  is  repeated  across  several  different 
settings  for  the  penalty  factor,  a,  as  described  by  the  Equation  6. 

From  criteria  (1)  above,  the  cutoff  TPR  =  90%  at  SNRthr  =  7.424  dB  is  shown 
by  the  intersection  of  the  dotted  lines  in  the  hgure.  Curves  that  pass  through  the 
upper  left  quadrant  meet  the  criteria  from  (1)  for  successful  preamble  detection.  As 
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Detection  Error  Rate 


Figure  47.  TPR  results  of  Monte  Carlo  simulation  for  various  a. 


shown  in  Figure  47,  only  values  where  1  <  a  <  5  stay  within  the  criteria. 

The  second  simulation  was  also  conducted  according  to  Section  4.3.2  and  used 
1,000,000  randomly  generated  samples  per  trial  run.  Each  sample  uses  a  randomly 
generated  signal  template  from  the  false  preambles  templates,  shown  in  Figure  41, 
with  noise  added  using  the  randn  MATLAB®  function  according  to  a  specihed 
level  of  Eii/Nq.  Figure  48  shows  the  FPR  across  different  values  of  Eh/No,  for  the 
penalty  factors  1  <  «  <  5  which  met  criteria  (1).  The  cutoff  FPR  at  SNRthr 
is  shown  by  the  intersection  of  the  dotted  lines  in  the  hgure.  All  curves  that  pass 
through  the  lower  left  quadrant  meet  criteria  (2)  for  successful  preamble  detection. 
As  shown  in  Figure  48,  the  a  values  of  3,4,  and  5  meet  the  criteria. 
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Detection  Error  Rate,  Normal  ADS-B  Signal 


Figure  48.  FPR  results  of  Monte  Carlo  simulation,  1  <  a  <  5. 


4.4.4  FPGA  Resource  Usage. 

The  Xilinx  Kintex-7  is  a  fairly  modern  FPGA,  compared  to  many  existing 
FPGA  components,  especially.  The  overall  FPGA  resource  consumption  expressed 
by  slices,  6-input  LUTs,  random  access  memory  (RAM)  (Kb),  shift  registers  (Kb), 
and  flip-flops.  Table  2  shows  the  total  available  for  each  resource  type  on  the  Kintex- 
7  (specihcally  the  Kintex-7K410T)  onboard  the  USRP™  X310. 

Based  on  the  system  design  and  implementation.  Table  3  shows  the  required 
FPGA  resource  utilization,  reflecting  the  portion  of  the  usage  attributable  to  the 
SADS-B  encryption  module  designed  during  the  course  of  this  research,  and  also 
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Table  2.  Total  Available  Kintex-7K410T  Resources 


Resource  Type 

Quantity  Available 

Slices 

63,550 

6-input  LUTs 

254,200 

RAM  (Kb) 

5,663 

Flip-Flops 

508,400 

the  total  including  the  overhead  from  the  inherited  USRP™  top  level  design. 


Table  3.  Kintex-7K410T  Resources  Used  by  SADS-B 


Resource  Type 

SADS-B  Module  Usage 

Total  Prototype  Usage 

Slices 

34,316 

54,219 

6-input  LUTs 

121,465 

174,560 

RAM  (Kb) 

299 

804 

Flip-Flops 

96192 

136,000 
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V.  Conclusions 


5.1  Research  Summary 

The  goal  of  this  research  was  to  prototype  and  characterize  an  implementation 
of  BITW  security  for  the  ADS-B  system.  Given  the  unique  structure  and  small  size 
of  ADS-B  information  messages,  and  based  on  previous  research,  the  FFX  algo¬ 
rithm  was  implemented  on  an  FPGA-based  platform.  The  prototype  was  designed, 
implemented,  and  verihed  using  system  engineering  principles  and  an  incremental 
approach. 

The  components  were  individually  verihed  through  the  modeling  and  simula¬ 
tion,  hardware  design  simulation,  and  hardware  implementation  using  various  tech¬ 
niques.  The  verihcation  criteria  were  based  on  the  intended  operating  environment. 
The  performance  of  the  system  as  a  whole  system  was  characterized  in  terms  of  la¬ 
tency,  throughput,  and  the  strength  of  the  detection  and  demodulation  schemes. 
The  latency  and  throughput  of  the  system  are  more  than  adequate  in  meeting  the 
requirements  for  a  transparent  BITW  security  system  for  ADS-B  and  would  be  ex¬ 
pected  to  perform  transparently  in  an  operating  context.  The  FPGA  utilization 
is  sufficient  for  implementation  of  a  single  SADS-B  module  (encryption  or  decryp¬ 
tion),  but  not  both  on  a  single  USRP^”  X310  prototype  device  without  further  opti¬ 
mization  or  utilization  of  a  larger  FPGA. 

Based  on  sub-millisecond  latency  and  a  verihed  end-to-end  design,  the  results 
of  this  research  suggest  that  FPE  (specihcally  FFX),  when  implemented  in  a  BITW 
architecture,  is  a  suitable  mechanism  for  layering  security  onto  the  existing  ADS-B 
infrastructure. 
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5.2  Future  Work 


The  practical  next  step  in  this  area  of  research  from  a  system  perspective  is 
to  miniaturize  the  prototyped  SADS-B  system  for  implementation  on  an  opera¬ 
tional  Unmanned  Aerial  Vehicle  (UAV).  To  do  this,  would  either  be  miniaturizing 
the  HDL  design  for  inclusion  in  an  already  existing  on-board  electronics  package,  or 
reducing  the  overall  size,  weight  and  power  required  and  analyzing  the  results. 

Several  cryptographic  enhancements  or  modihcations  could  be  be  proposed  for 
use  with  the  current  SADS-B  prototype.  A  cryptographic  recommendation  from 
Jochum  was  to  preclude  the  CRC  bits  in  the  message  from  being  included,  then  re¬ 
calculating  them  for  the  new  packet/frame  prior  to  transmission  [15].  This  would 
allow  the  receiver  to  validate  the  encrypted  SADS-B  packet  before  decryption,  pro¬ 
cessing,  and  transmittal  to  the  ADS-B  IN  receiving  device.  The  DF-19  military 
channel  has  no  readily  available  specihcations  for  the  use  of  the  associated  CA 
codes.  This  held  could  be  used  in  conj notion  with  a  public  key  infrastructure  (PKI) 
scheme  to  securely  distributed  updated  symmetric  keys  via  asymmetric  cryptogra¬ 
phy,  similar  to  Secure  Sockets  Layer  (SSL)  in  the  internet  space.  Additionally  (or 
alternatively)  the  addition  of  an  integrity  check  such  as  a  message  authentication 
code  (MAC)  could  be  included  in  place  of  the  CRC  check  or  as  an  augmentation  of 
it. 

The  performance  standards  that  built  the  basis  for  the  preamble  detector  have 
a  section  on  enhanced  preamble  detection  [21].  This  material  could  be  used  to  op¬ 
timize  the  SADS-B  prototype  in  the  decryption  conhguration  to  maximize  perfor¬ 
mance  in  the  context  of  closer-to-real-world  conditions. 
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5.3  Contributions 


This  research  generated  a  real-time  ADS-B  prototype  with  verification  resnlts 
that  snpports  its  operational  feasibility  and  ntility.  It  validated  the  prototype  against 
performance  reqnirements  specified  for  ADS-B  1090ES,  snpporting  the  feasibility  of 
adding  the  S ADS-B  layer  of  secnrity  on  top  of  ADS-B  in  a  military  context. 

It  also  made  strides  towards  a  development  framework  for  BITW  encryption, 
inclnding  fnrther  enhancements  to  ADS-B  secnrity  or  BITW  implementation  in 
other  commnnications  contexts  or  applications.  This  framework  inclndes  the  con- 
tribntion  more  than  4,000  lines  of  MATLAB®,  VHDL,  and  Verilog  code. 
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Appendix  A. 


Figure  49.  Frequency  response  of  analog  front  end  on  USRP™  SBX-40  daughter¬ 
board. 
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14.  ABSTRACT 

During  sensitive  military  operations,  such  as  air  operations  in  theater,  the  broadcasting  of  ADS-B  messages  poses  a 
serious  security  concern,  but  the  small  message  payload  of  ADS-B  transmissions  renders  encryption  standards  such  as 
AES  unsuitable.  Format-preserving  encryption  (FPE),  a  technique  already  in  use  on  small  message  sizes  such  as  credit 
card  numbers,  provides  a  suitable  implementation  of  strong  symmetric  key  encryption  for  the  military  context.  This 
research  proposes  and  details  a  Secure  ADS-B  (SADS-B)  system  which  utilizes  a  bump-in-the-wire  approach  for 
encryption  and  decryption  of  ADS-B  messages  using  FPE,  going  on  to  then  characterize  the  prototype’s  performance 
using  the  following  metrics:  detection  and  error  rates,  operational  latency,  and  utilization  of  resources  on  the  underlying 
field  programmable  gate  array  (FPGA)  hardware.  Findings  include  sub-millisecond  operational  latency,  full  data  rate 
throughput  capability  for  ADS-B,  and  approximately  50%  utilization  of  the  available  FPGA  resources.  Overall,  findings 
suggest  that  a  layered  security  system  such  as  SADS-B  is  suitable  for  adding  confidentiality  to  ADS-B. 


15.  SUBJECT  TERMS 


NextGen,  ADS-B,  FAA,  FPGA,  format  preserving  encryption,  FFX 


16.  SECURITY  CLASSIFICATION  OF: 

17.  LIMITATION  OF 
ABSTRACT 

18.  NUMBER 
OF 

PAGES 

19a.  NAME  OF  RESPONSIBLE  PERSON 

Dr.  Robert  F.  Mills,  PhD  (ENG) 

a.  REPORT 

b.  ABSTRACT 

c.  THIS  PAGE 

u 

u 

u 

uu 

78 

19b.  TELEPHONE  NUMBER  (include  area  code) 

(937)  255-3636  x4527  Robert.Mills@afit.edu 

Standard  Form  298  (Rev.  8-98) 

Prescribed  by  ANSI  Std.  Z39.18 


